DBD::Oracle's Persistent OCI Environment

Mr. Muskrat on 2009-06-05T15:36:57

Background:
We have been writing all of our security related information to /var/log/secure. We typically use two database handles in our applications: one for the operator logged in and one for administrative purposes. The operator has just enough privileges to do what he or she needs to do in the application. We recently upgraded to Red Hat Enterprise Linux 5.3 64-bit, Oracle 11 Standard 64-bit, DBI 1.607 and DBD::Oracle 1.22 and everything was happy.

About a week ago we started putting that info into the database as well and everything was running wonderfully. That is until someone mistyped his or her password -- then we started seeing odd behaviors. It started out looking like a return was failing to return and instead crashing the app. One person was working through our code looking for something that had changed and added a cluck before the return in an attempt to shed some light on the situation. The app mysteriously made it further along but started crashing with a OCIHandleAlloc failure.

I found some information on the web that indicated that we might be falling back on 32-bit libraries. Our LD_LIBRARY_PATH environment variable turned out to indeed be pointing to 32-bit libraries so I fixed it. The problem persisted.

I saw that were newer versions of DBI (1.608) and DBD::Oracle (1.23). The DBI install went off without a problem. DBD::Oracle 1.23 was failing LOB tests (a known issue without a resolution) so I kept it at 1.22. The problem persisted.

Next I enabled trace level 1. I logged in using a valid username but an invalid password. That is when I saw that, while we were using two database handles, DBI/DBD::Oracle was refusing to accept the good admin connection as good after the bad connection attempt was made.

Then another coworker pointed out that by default, DBD::Oracle reuses the OCI environment for subsequent connections. Usually this is a good thing but it was causing us problems. Fortunately, the solution was as simple as adding ora_envph => 0 to our connection options. I also removed that cluck and it remained fixed.